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Abstract 

We define focus-method interfaces and some connections between such interfaces and 
instruction sequences, giving rise to instruction sequence components. We provide a 
flexible and practical notation for interfaces using an abstract datatype specification 
comparable to that of basic process algebra with deadlock. The structures thus defined 
are called progression rings. We also define thread and service components. Two types 
of composition of instruction sequences or threads and services (called 'use' and 'apply') 
are lifted to the level of components. 



1 Introduction 

We can not simply say that this instruction sequence (inseq) has that interface because there 
are different ways to obtain an interface from an inseq, which is one the main questions that 
we deal with in this paper. Instead we will do this: 

(i) we define and formalize so-called focus-method interfaces, or briefly, FMIs, 
(m) we specify some relations between FMIs and inseq's, and 

(Hi) we define an inseq component as a pair (i, P) of an FMI i and an inseq P where i and 
P need to be related in the sense meant in (ii) above. 

Focus method interfaces will also serve as thread-component interfaces, whereas Mis (method 
interfaces) will be used as service-component interfaces. 

Like with an instruction sequence, a thread component results by pairing a thread and an 
FMI, and a service component consists of a pair of a service and an MI. 



*The authors acknowledge support from the NWO project Thread Algebra for Strategic Interleaving. 
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Using focus-method notation (FMN) a basic instruction has the form 
f .m 

where f is a focus and m is a method. Furthermore, we have the following test instructions: 

+f .m (a positive test instruction) 
—f.m (a negative test instruction) 

Some examples of instructions in FMN are: 

bl7. set: true and +bl8a.get 

where bl7 and bl8a are foci addressing certain boolean registers, and set: true and get are 
methods defined for such boolean registers. 

The idea of a positive test instruction is that upon execution it yields a reply true or false, 
and that upon the reply true execution continues with the next instruction, while upon reply 
false the next instruction is skipped and execution continues with the instruction thereafter. 
The execution of a negative test instruction displays the reversed behavior with respect to the 
reply values. Note that the reply values true and false have nothing to do with the example 
method set: true mentioned above. 

In |BL02| the programming notation PGLB is defined: Next to a given set A of basic 
instructions and the test instructions generated from A, PGLB contains forward jumps #fc and 
backward jumps for /c G N as primitive instructions, and a termination instruction which is 
written as !. The instructions mentioned here are PGLB's so-called primitive instructions. The 
inseqs that we call PGLB programs are formed from primitive instructions using concatenation, 
notation ;. The following three inseqs are examples of PGLB programs: 

bl7 . set : true 

-|-bl8a . get; #2; bl7 . set : true 

— bl . get; f/=3; b4 . set : false; ^^3; b4 . set : true; ! 

We consider PGLB as an inseq notation, and we assume that adaptations to other inseq 
notations can easily be made. 

In |BL02| it is defined in what way a PGLB program defines a thread. Here we now discuss 
the interface of such inseqs. Consider 

P = -bl . get; #3; b4 . set : false; #3; b4 . set : true; ! 

It is reasonable to view 

{bl . get, b4 . set : false, b4 . set : true} 

as the interface of P. We will call this a focus-method interface (FMI) for P as it consists of 
focus-method pairs. 
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For an interface it is important that its description is "simple" . If an interface of inseq P is 
automatically derived from P then storage of that interface as a part of the code is a matter 
of pre-computation. 

These pre-computed datastructm'es should be easy to store and easy to use. This "use" can 
be a matter of application of static checks which prevent the occurrence of dynamic errors. It 
follows that one needs a notation for interfaces which allows notational simplification. 

Writing + for union and omitting brackets for single elements one may write 

{bl . get, b4 . set : false. b4 . set : true} ~ bl . get + b4 . set : false + b4. set : true 

= bl . get + b4 . set : (false + true) 
= b(l .get + 4.set : (f als + tru)e) (1) 

We find that this notation allows useful simplifications. The main contents of this paper is to 
specify the details of this particular interface notation. 

We notice that if i is a plausible interface for inseq P, it may be the case that some i' 
extending i can be denoted with a significantly more simple FMI-expression, say jg. Then 
is also a plausible interface for P. We will provide technical definitions of various forms of 
matching inseq's with interfaces in such a way that this intuition can be made formal. 

From a mathematical point of view the task to provide the details of the interface notation 
as suggested in ((T|) is not at all challenging. From the point of view of abstract data type 
specification it requires the explicit resolution of several design alternatives, each of which have 
advantages and disadvantages. In particular, insisting that interface elements are in FMN, 
one needs to resolve some language/meta-language issues in order to provide an unambiguous 
semantics of interface expressions. 

We hold that from some stage onwards the theory of instruction sequences needs to make 
use of a pragmatic theory of interfaces. It is quite hard to point out exactly when and where 
having full details of an interface notation available matters. For that reason we have chosen to 
view the design of an interface notation for instruction sequences as an independent problem 
preferably not to be discussed with a specific application in mind. 

Summing up, this is the question posed and answered below: 

Assuming that instruction sequence interfaces are important per se, provide a 
flexible and practical notation for interfaces by means of an appropriate abstract 
datatype specification. 

The paper is structured as follows: In the next section we introduce progression rings and 
show how they underly an abstract datatype specification for interfaces. In Section[3]we define 
inseq components and thread components, and in Section [4] we discuss composition of such 
components with service components. In Section [5] we briefly discuss interfaces that are not 
minimal and make a remark about related work. 
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2 Progression Rings and Interfaces 



We first formally define the letters, lower case and upper case in BNF-notation (enclosing 
terminals in double quotes): 

Vllc ■■■■= "a" I "b" I "c" I ... I "z" (26 elements) 
Vluc ■■■■= "A" I "B" I "C" I ... I "Z" (26 elements) 
Vl :■■= Vllc I Vluc 

Furthermore, we shall use digits (Vd), the colon and the period as terminals for identifiers: 

Vd ::= "0" I ... I "9" 
Vc ":" 
Vldc ■■■■= Vl I Vd \ Vc 
Vp ::= "." 
Vldcp ■■— Vldc I Vp 

Let / be the set of interfaces. Elements of Vldc and Vp (thus of Vldcp) are considered 
constants for /, and 

S 

is a special constant denoting the empty interface. Furthermore, X,Y,Z,... are variables 
ranging over /. 

On / we define + and • as alternative and sequential composition, where • binds stronger 
than + and will be omitted whenever possible. As usual, we use the notation V^ for the set 
of finite strings over alphabet V. 

Consider a string, say (3 — a7:b.b25:8.c in (Vldcp)^ ■ The string (3 is understood as a 
selector path to be read from left to right. Stated in different terms, /3 contains a progression 
of information separated by periods (".") to be understood progressively from left to right. 
For this reason we will call P a progression. The notion of a progression thus emerging 
combines that of a string or word and that of a process. A process in a bisimulation model 
can be considered a branching progression where progression is thought in terms of time or 
less abstract in terms of causality. 

Having recognized interfaces as progressions it is a straightforward decision to take an 
existing algebraic structure of progressions as the basis of their formal specification. To this end 
we provide the axioms of Basic Process Algebra with S, or briefly, BPA5 (see [BW90| IFokOOj ) 
in Table m 

Definition 1. A right progression ring is a structure that satisfies the equations of BPAs 
(see Tafe/e Qp. 

Thus sequential composition • is right distributive over + in a right progression ring and S 
is its additive identity. Furthermore, (5 is a left zero element for sequential composition. 

For the sake of completeness we also define left progression rings. 
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Table 1: The axioms of BPA^ 



X + Y = Y + X 
{X + Y) + Z = X + {Y + Z) 
X + X = X 



{X + Y) ■ Z = X -Y + X ■ Z X + S = X 
{X -Y) ■ Z = X ■ (Y ■ Z) 6-X = 6 



Definition 2. A left progression ring is a non- commutative ring with respect to sequential 
composition, in which + is commutative, associative and idempotent, and sequential compo- 
sition ■ is left distributive over +. Furthermore there is a constant 6 that is both the additive 
identity and a right zero element for sequential composition. 

So a left progression ring satisfies the axioms 

X ■ {Y + Z) = X -Y + X ■ Z instead of {X + Y) ■ Z = X ■ Y + X ■ Z, 
X ■ 6 ^ 5 instead of S ■ X ^ S. 

A right or left progression ring is distributive if • is distributive over +. 

^LDCP is the initial distributive right progression ring with constants taken from Vldcp- 
In this paper we will only consider Ildcp a-s a structure for interfaces. We will omit the 
symbol • in a sequential composition whenever reasonable. In the case that we consider closed 
terms that are built with sequential composition only, we will certainly omit this symbol, and 
for example write 

bll4.get instead of for example bl • 14 ■ .get 

although these two expressions of course represent the same closed term. Observe that when 
adopting this convention, each /3 G {Vldcp}'^ can be seen as an element (an interface, a closed 
term) in Ildcp- 

We notice that most process algebras as found in |BK84i IB W90[ IFokOO| are (non-distributive) 
right progression rings, some unital (i.e., containing a unit for sequential composition). 

In Ildcp we write 

X HY if X + Y = Y. 

(Vldcp)^ we need two additional operators on Ildcp- 

the /3-derivative of X: 

yields the largest Y such that either Y — SorX + (3-Y\ZX, 

— (X) the /3-filter-complement of X: 

removes all progressions from X which have P as an initial segment. 



For each /? e 
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For example, 
d 



d 



5a. b 



(a. + a.b + a. be) = c = (a. be) 

aa.b 



and 



(a. + a.b + a.bc) = a. = - — -(a.). 



5a. b 



aa.b 



Both these operators can easily be defined. Let u,v ^ Vldcp and (3 € (Vldcp)^) then the 
d 

/^-derivative 7r-r(_) is defined as follows: 
op 



d d d 



d 



du 



d 



d 



■^XX + Y) = -iX) + -iY) 



du 



du 



d_ 
du 



{vX) = 



5 ifv^u, 
X otherwise, 



and the /3-filter-complement — (_) is defined by: 



du 



{5) = 5, 



dup 



{5) = 8, 



d_ 
du 



d_ 
du 



iv) 



if V u, 
otherwise. 



vX if V u, 
S otherwise, 



duf} 



{v) = V, 



dul3 



vX if either v ^ u, or v = u 
d 

{vX) = { and —{X) ^6, 

d 

if V = u and ^(^) = ^• 
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3 Instruction Sequence and Thread Components 



A focus-method interface (FMI) is an interface which is provably equal to either 5 or a term 
of the form 



with Pi, (3ij G Vl(Vldc)^ and k,kij > 0. Informally stated this means that after flattening 
(bringing + to the outside), we have words with exactly one period each and no words ending 
in S. 

Let i € Ildcp be an expression denoting some FMI (thus i ^ 5). Then PGLB; is the 
instruction sequence notation with basic instructions taken from i. The number of possible 
basic instructions may grow exponentially with the size of the expression i. 

Example 1. Consider the interface i defined by 



which abbreviates 1 + 2 • 3'^ + 7 62 basic instructions (and the availability of twice as much 
test instructions in PGLBi). 

Here we notice a first reward of our formalization: a flexible specification format for a 
wide variety of different instruction sequence notations. Instead of PGLB one might of course 
use other other program notations such as PGA, PGLC or PGLD from |BL02| . PGLA from 



In [BP02j a 'program component' [i, P] is defined as a pair of an interface and a program 
with the requirement that i contains at least all instruction names that occur in program P. 
We stick to this idea and hold that an instruction sequence component is a pair 



of a focus-method interface i and an instruction sequence P, where some form of match 
between i and P needs to be assumed. We have a number of options which wc will formally 
distinguish: 

Definition 3. Let P be some inseq in FMN. Then P requires interface i if each element f .m 
of i occurs in P and conversely, all basic instructions occurring in P are elements of i, where 
f .m occurs in P if at least one o/f .m, +f .m, — f .m is an instruction of P. 

Furthermore, P subrequires interface i if for some j, j C i and P requires j, and P 
properly subrequires i if for some j, j ^ i, j i and P requires j. 

For example, 



f .(get + (set: + testeq:)(0 + 1 + 2)(0 + 1 + 2)(0 + 1 + 2)) + 
g. (get + (set + testeq)( : )(true + false + error)) 



(2) 



[BP08] . or C from [BP09] . 




requires b2 . set : false, 

subrequires b2 . set : false + i for any interface i. 
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For threads we can consider thread components as pairs {i,T). The definitions of T requires 
i and T subrequires i are obvious: 

Definition 4. Let T be some thread with actions in FMN. Then T requires interface i if 
each element of i occurs in T and conversely, all actions occurring in T are elements of i . 

Furthermore, T subrequires interface i if for some j , j \— i and T requires j , and T 
properly subrequires i if for some j, j \— i, j ^ i and T requires j. 

As an example, |^3; b2 . set : false; ! ; ! | (sub)requires S. Using these last two definitions, 
we can refine the (sub)-requirement notions as follows. 

Definition 5. Let i be an interface and P an inseq. Then P 1-requires i if \P\ requires i, 
P sub-l-requires i if \P\ subrequires i , P (sub-)n-requires i if \^n; P\ ( sub) requires i, and 
P (sub-){l, n)-requires i if for all m with 1 < m < n, P (sub-)m-requires i. 

For example, 

:j^3; b2 . set : false; !; ! (sub)- 1-requires ^, but (sub)-2-requires b2 . set : false. 

Let c — {i, P) be an instruction sequence component. By default we assume that P subre- 
quires i unless explicitly stated otherwise. We further call i the interface of c and P the body 
of c. So for an instruction sequence component c it may for instance be the case that its body 
(sub-)(l, 7)-requires its interface. Here are some elementary connections: 

• if P subrequires i then for all n, P sub-n-requires i, 

• conversely, if for all n, P sub-n-requires i then P subrequires i, 

• if for m = 1,...,£{P), where £{P) is the length of P (its number of instructions), P 
m- requires im then P requires +mlliim- 

Further decoration of an inseq component with for instance information about its inseq 
notation is possible but will not be considered here. 

4 Service Components 

For a service H we assume that it offers processing for a number of methods collected in 
a method interface. Thread-service composition is briefly explained in |PZ06j : inseq-service 
composition was introduced in ^BP02j (where services were called 'state machines') and de- 
fined as the composition obtained after thread extraction of the program term involved. The 
definition of a service H includes that of its reply function, the function that determines the 
reply to a call of any of its methods (which in general is based on initialization assumptions 
and on its history, i.e., the sequence of earlier calls). Furthermore, there is a so-called empty 
service that has the empty method interface 6. 

A method interface (MI) is either S or is created by -I- and • from constants in Vldc- 
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Example 2. A stack over values 0, 1 and 2 can be defined as a service with methods push: z, 
topeq:z , and pop, for i = 0, ...,2, where push:z pushes i onto the stack and yields true, the 
action topeq:z tests whether i is on top of the stack, and pop pops the stack with reply true 
if it is non-empty, and otherwise does nothing and yields false. 

With /? ranging over (Vldc)* , the reply function F of the stack is informally defined by 

F{f3 ■push: i) = true and generates a stack with i on top 

true if the stack generated by /? is non-empty 
and then pops this stack, 
otherwise, 

if the stack generated by /3 has i on top 
otherwise. 




F((3 topeq: i 



For a formal definition of a stack as a service, see e.g. [PZ06j . 

Definition 6. A service H provides interface i if H offers a reply function for all elements 
of i, and H superprovides i if for some j ^ i, H provides j. 

For a service component (j, H) we assume that H superprovides the method interface j 
unless explicitly stated otherwise. 

Below we consider two forms of inseq-service composition: the use and the apply composi- 
tion. We first discuss the use operator. For an inseq P a use application is written 

where /? is a focus. A use application always yields a thread, which is reasonable because it is 
upon the execution of an inseq that its generated actions may call for some service and use its 
reply for subsequent execution. The use operator simply drops the service upon termination 
or deadlock. Use compositions are defined in |BP02| and take a thread as their left argument, 
but inseqs can be used instead by setting P/p H — \P\/ p H. Below we lift use compositions 
to the level of components. 

Example 3. The stack described in Example [2] provides the method interface j defined by 
j = (push : + topeq : ) (0 + 1 + 2) pop. (3) 

Let P be a program defined in PGLBi+c.j for the FMI i defined in Example [TJ Then P 
can use the stack defined in Example [2] via focus c. If we only push the value (so the stack 
behaves as a counter), we can write C{n) for a stack holding n times the value (so C(0) 
represents the empty stack). With the defining equations from |BP02j it follows that 

(c.push:0;P)/cC(n) =P/cC(n + l), 
(-c.pop; !;P)/c C(0) = S, 
(-C . pop; ! ; P)U C{n + 1) = P/c c C{n). 

Instructions in PGLBi-|_c.j with foci different from c are distributed over use applications, e.g., 

(+g. set: true; f. get; P)/c C(n) = ((f .get;P)/e C(n)) <g.set:true> (P/c C(n)). 
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Definition 7. For an instruction sequence component {i,P), a service component {j,H), and 
some P £ ^LDC '"'^^ composition 

(i,P)/p {j,H) 

d . d 

is matching if (i) C j (note the period that occurs in ), in which case 

d 

The use composition {i, P)/ p {j, H) is non-matching if ^^(*) 2 j '^'^'^ then 

{i,P)/p{j,H) = {5, D). 
Example 4 (Example [3] continued). We find for inseq component (i + c.j, c.pusli:0;P) that 

(z + c.j, c.push:0;P)/e = (z, P/cC(n+l), 

while (i, c.push:0;F)/c 0',C(n)) = ((5, D). 

The apply composition of a thread T and a service H is written 

and always yields a service. Thus threads are used to alter the state of a particular service, 
and only finite threads without deadlock (D) do this in a meaningful way. Apply compositions 
are defined in [BP02j and take a thread as left-argument, and a typical defining equation is 

S*pH = H. 

However, we can use inseqs as left-arguments by defining P up H ^ \P\ •p H. Below we lift 
apply compositions to the level of components. 

Definition 8. For an instruction sequence component {i,P), a service component {j,H), and 
some (3 G V^j^fj, the apply composition 

{t,P) .p {j,H) 
is matching if i □ f3 .j and then 

{t,P),p{j,H)^{j, P.pH). 
The apply composition {i,P) *p (j, -ff) is non-matching ifi% fi.j and then 

{i,P).p U,H) = {S, 0) 
where is the empty service. 

Example 5. For the stack and the interfaces i and j defined in Examples [SHU we find 

(c.j, c. push :0;c. push :0; ! ) .c {j,C{n)) = {j,C{n + 2)), 
while (i, c. push : 0; c. push: 0; ! ) {j,C{n)) — (6, 0). 
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5 Plots and Related Work 



By allowing interfaces which are not mimimal (subrequired) more options arise for finding 
concise interface notations. One might question the plausibility of components with interfaces 
which are larger than strictly necessary. Here are some plots that might lead to that situation. 

1. {i, P) with P the result of complex projections that are not yet computed. 

2. {i, P) with P projected to PGLB in fragments (JIT projection). At no point in time the 
complete interface of P is known. 

3. claims name space while preventing redesign of relevant methods of the services 
used. This creates degrees of freedom for redesign of P. For example, if P uses booleans 
bl, ...,b50, one can reserve bl, ...,blOO to facilitate future ideas to optimize P. 

4. (i, P) is one of a series inseq components that one may want to plug in in an execution 
architecture [BP07| . The interface i is kept simple to facilitate a quick check. 

Without any doubt, more plots that justify the existence of inseq components can be thought 
of. However, as stated earlier, the main argument for the introduction of (right) progression 
rings introduced in this paper is to provide a flexible and practical notation for interface 
specification by means of an appropriate abstract datatype specification. 

In [BM07| , a process component is taken as a pair of an interface and a process specifiable 
in the process algebra ACP |BW90[ IFokOOj . In that paper interfaces are formalized by means 
of an interface group, which allows for the distinction between expectations and promises 
in interfaces of process components, a distinction that comes into play in case components 
with both client and server behaviour are involved. However, in our approach the interaction 
between instruction sequences (or threads) and services is not sufficiently symmetric to use 
the group structure. 
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